--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
docs/source/git.rst 0f33d71966b69d5a15819106b53edab4c6cfb355 (0f33d719) Text, 63.59 KB
Tb4b4b4.. Tff7b72_git-main:
Tc9d1d9******************
Tc9d1d9Git Over Reticulum
Tc9d1d9******************
This chapter of the manual serves as the technical reference for the distributed software development and project collaboration tools included in RNS. For a conceptual overview, see the Te6edf3:ref:Te6edf3`Distributed Development<distributed-development>` chapter.
A set of utilities for distributed collaborative software development and publishing are included in RNS.
The system consists of two parts: The Ta5d6ff``Ta5d6ffrngitTa5d6ff`` node that hosts repositories, and the Ta5d6ff``Ta5d6ffgit-remote-rnsTa5d6ff`` helper that enables Git to communicate with rngit nodes. As soon as you have RNS installed on your system, you can transparently use Git with Reticulum-hosted repositories just like any other type of remote. Git over Reticulum uses URLs in the following format: Ta5d6ff``Ta5d6ffrns://DESTINATION_HASH/group/repoTa5d6ff``.
If you set a branch to track a Reticulum remote as the default upstream, you can simply use Ta5d6ff``Ta5d6ffgitTa5d6ff`` as you normally would; all commands work transparently and as expected.
Tb4b4b4.. Tff7b72importantTb4b4b4::
**The rngit program is a new addition to RNS!** This functionality was introduced in RNS 1.2.0. While great care has been taken to design a secure, but highly configurable and flexible Ta5d6ff`permission system`_ for allowing many users to interact with many different repositories on a single node, Ta5d6ff``Ta5d6ffrngitTa5d6ff`` has not been tested extensively in the wild! Be careful when hosting repositories, especially if they are public or semi-public.
Tb4b4b4 .. Tff7b72_permission system: #permissions
Tc9d1d9The rngit Utility
Tc9d1d9=================
The Ta5d6ff``Ta5d6ffrngitTa5d6ff`` utility provides full Git repository hosting and interaction over Reticulum. It allows you to host and manage Git repositories and releases on Reticulum nodes, and to interact with remote repositories using standard Git commands through the Ta5d6ff``Ta5d6ffrns://Ta5d6ff`` URL scheme.
**Usage Examples**
Run Ta5d6ff``Ta5d6ffrngitTa5d6ff`` to start a repository node:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit
[Notice] Starting Reticulum Git Node...
[Notice] Reticulum Git Node listening on <0d7334d411d00120cbad24edf355fdd2>
On the first run, Ta5d6ff``Ta5d6ffrngitTa5d6ff`` will create a default configuration file. You will then need to edit this, to point to your repository locations, configure access permissions, and perform any other necessary configuration.
Them, view your identity and destination hashes:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit --print-identity
Git Peer Identity : <959e10e5efc1bd9d97a4083babe51dea>
Repository Node Identity : <153cb870b4665b8c1c348896292b0bad>
Repositories Destination : <0d7334d411d00120cbad24edf355fdd2>
If the page node is enabled, the output will also include the Nomad Network destination hash.
You can run Ta5d6ff``Ta5d6ffrngitTa5d6ff`` in service mode with logging to file:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit -s
Clone a repository from a remote Ta5d6ff``Ta5d6ffrngitTa5d6ff`` node:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ git clone rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo
Add a Reticulum remote to an existing repository:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ git remote add some_remote rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo
Push changes to the Reticulum remote:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ git push some_remote master
Get changes from a remote repository:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ git pull rns_remote master
Fork an existing repository from a remote to your Ta5d6ff``Ta5d6ffrngitTa5d6ff`` node:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit fork rns://8a37cdd16938ce79861561adbd59023a/reticulum/lxmf rns://50824b711717f97c2fb1166ceddd5ea9/public/myfork
**All Command-Line Options (rngit)**
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
usage: rngit.py [-h] [--config CONFIG] [--rnsconfig RNSCONFIG] [-s] [-i] [-v]
[-q] [--version]
Reticulum Git Repository Node
options:
-h, --help show this help message and exit
--config CONFIG path to alternative config directory
--rnsconfig RNSCONFIG
path to alternative Reticulum config directory
-p, --print-identity print identity and destination info and exit
-s, --service rngit is running as a service and should log to file
-i, --interactive drop into interactive shell after initialisation
-v, --verbose increase verbosity
-q, --quiet decrease verbosity
--version show program's version number and exit
**All Command-Line Options (git-remote-rns)**
The Ta5d6ff``Ta5d6ffgit-remote-rnsTa5d6ff`` helper is automatically invoked by Git when interacting with Ta5d6ff``Ta5d6ffrns://Ta5d6ff`` URLs. It is not typically run directly by users, but accepts the following environment variables for configuration:
T79c0ff- Ta5d6ff``Ta5d6ffRNGIT_CONFIGTa5d6ff`` - Path to alternative client configuration directory
T79c0ff- Ta5d6ff``Ta5d6ffRNS_CONFIGTa5d6ff`` - Path to alternative Reticulum configuration directory
The client configuration file is located at Ta5d6ff``Ta5d6ff~/.rngit/client_configTa5d6ff`` and allows adjusting parameters such as the reference batch size for transfers.
Tc9d1d9Repository Creation & Management
Tc9d1d9================================
The Ta5d6ff``Ta5d6ffrngitTa5d6ff`` utility provides several ways to create and manage repositories on a node: creating empty repositories, forking from existing repositories, and mirroring remote repositories.
Tc9d1d9Creating Empty Repositories
Tc9d1d9---------------------------
To create a new empty repository on a remote node:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit create rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo
Repository public/myrepo created
This creates a bare Git repository at the specified path. You must have Ta5d6ff``Ta5d6ffcreateTa5d6ff`` permission for the target group. When a repository is created, the creator automatically receives Ta5d6ff``Ta5d6ffadmTa5d6ff`` (admin) permissions on the repository through an auto-generated Ta5d6ff``Ta5d6ff.allowedTa5d6ff`` file.
**All Command-Line Options (rngit create)**
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
usage: rngit create [-h] [--config CONFIG] [--rnsconfig RNSCONFIG]
[-i PATH] [-v] [-q] [--version]
repository
Reticulum Git Repository Creation
positional arguments:
repository URL of repository to create
options:
-h, --help show this help message and exit
--config CONFIG path to alternative config directory
--rnsconfig RNSCONFIG
path to alternative Reticulum config directory
-i, --identity PATH path to identity
-v, --verbose
-q, --quiet
--version show program's version number and exit
Tc9d1d9Forking Repositories
Tc9d1d9--------------------
Forking creates a copy of an existing repository (from any accessible Git URL) on your Ta5d6ff``Ta5d6ffrngitTa5d6ff`` node. Forks maintain a reference to their upstream source for later synchronization.
To fork a repository:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit fork https://github.com/user/original rns://50824b711717f97c2fb1166ceddd5ea9/public/myfork
Repository forked to public/myfork
The source can be any valid Git URL, including:
T79c0ff- HTTPS URLs: Ta5d6ff``Ta5d6ffhttps://github.com/user/repo.gitTa5d6ff``
T79c0ff- SSH URLs: Ta5d6ff``Ta5d6ffssh://git@host.com/repo.gitTa5d6ff``
T79c0ff- Reticulum URLs: Ta5d6ff``Ta5d6ffrns://DESTINATION_HASH/group/repoTa5d6ff``
Forks are created as bare repositories with metadata tracking their origin. The fork process:
T79c0ff1. Creates a new bare repository
T79c0ff2. Fetches all refs (Ta5d6ff``Ta5d6ff+refs/*:refs/*Ta5d6ff``) from the source
T79c0ff3. Sets Ta5d6ff``Ta5d6ffrepository.rngit.typeTa5d6ff`` to Ta5d6ff``Ta5d6ffforkTa5d6ff``
T79c0ff4. Sets Ta5d6ff``Ta5d6ffrepository.rngit.upstream.sourceTa5d6ff`` to the source URL
T79c0ff5. Grants creator admin permissions
**All Command-Line Options (rngit fork)**
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
usage: rngit fork [-h] [--config CONFIG] [--rnsconfig RNSCONFIG]
[-i PATH] [-v] [-q] [--version]
source target
Reticulum Git Repository Forker
positional arguments:
source URL of source repository
target URL of target repository
options:
-h, --help show this help message and exit
--config CONFIG path to alternative config directory
--rnsconfig RNSCONFIG
path to alternative Reticulum config directory
-i, --identity PATH path to identity
-v, --verbose
-q, --quiet
--version show program's version number and exit
Tc9d1d9Mirroring Repositories
Tc9d1d9----------------------
Mirrors are similar to forks but are designed for keeping a local copy synchronized with an upstream repository. Mirrors can be automatically updated on a configurable schedule.
To create a mirror:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit mirror https://github.com/user/upstream rns://50824b711717f97c2fb1166ceddd5ea9/public/mymirror
Repository mirrored to public/mymirror
Mirrors are created with the same process as forks, but with Ta5d6ff``Ta5d6ffrepository.rngit.typeTa5d6ff`` set to Ta5d6ff``Ta5d6ffmirrorTa5d6ff`` and an additional Ta5d6ff``Ta5d6ffrepository.rngit.upstream.syncTa5d6ff`` timestamp tracking the last successful synchronization.
**All Command-Line Options (rngit mirror)**
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
usage: rngit mirror [-h] [--config CONFIG] [--rnsconfig RNSCONFIG]
[-i PATH] [-v] [-q] [--version]
source target
Reticulum Git Mirror Management
positional arguments:
source URL of source repository
target URL of target repository
options:
-h, --help show this help message and exit
--config CONFIG path to alternative config directory
--rnsconfig RNSCONFIG
path to alternative Reticulum config directory
-i, --identity PATH path to identity
-v, --verbose
-q, --quiet
--version show program's version number and exit
Tc9d1d9Automatic Mirror Synchronization
Tc9d1d9--------------------------------
The Ta5d6ff``Ta5d6ffrngitTa5d6ff`` node can automatically keep mirrors synchronized with their upstream sources. This is configured in the main configuration file:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
[rngit]
mirror_interval = 24
The Ta5d6ff``Ta5d6ffmirror_intervalTa5d6ff`` specifies the synchronization interval in hours (default: 24). The node checks for mirrors needing sync every 15 minutes, and fetches updates from upstream if the configured interval has elapsed since the last sync.
For automatic sync to happen, the repository must have been created with Ta5d6ff``Ta5d6ffrngit mirrorTa5d6ff``. Sync failures are logged but do not prevent future retry attempts. The sync timestamp is only updated on successful completion.
Tc9d1d9Manual Synchronization
Tc9d1d9----------------------
Both forks and mirrors can be manually synchronized on demand using the Ta5d6ff``Ta5d6ffsyncTa5d6ff`` command:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit sync rns://50824b711717f97c2fb1166ceddd5ea9/public/myfork
Repository synced
This fetches all refs from the upstream source configured when the repository was created. You must have Ta5d6ff``Ta5d6ffreadTa5d6ff`` and Ta5d6ff``Ta5d6ffwriteTa5d6ff`` permissions for the repository to perform a manual sync.
For mirrors, manual sync also updates the sync timestamp, effectively resetting the automatic sync timer.
**All Command-Line Options (rngit sync)**
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
usage: rngit sync [-h] [--config CONFIG] [--rnsconfig RNSCONFIG]
[-i PATH] [-v] [-q] [--version]
repository
Reticulum Git Repository Syncer
positional arguments:
repository URL of repository
options:
-h, --help show this help message and exit
--config CONFIG path to alternative config directory
--rnsconfig RNSCONFIG
path to alternative Reticulum config directory
-i, --identity PATH path to identity
-v, --verbose
-q, --quiet
--version show program's version number and exit
Tc9d1d9Git Configuration Parameters
Tc9d1d9----------------------------
Repositories created through Ta5d6ff``Ta5d6ffrngitTa5d6ff`` store metadata in Git configuration:
T79c0ff- Ta5d6ff``Ta5d6ffrepository.rngit.typeTa5d6ff`` - Either Ta5d6ff``Ta5d6ffforkTa5d6ff`` or Ta5d6ff``Ta5d6ffmirrorTa5d6ff``
T79c0ff- Ta5d6ff``Ta5d6ffrepository.rngit.upstream.sourceTa5d6ff`` - The source URL used during creation
T79c0ff- Ta5d6ff``Ta5d6ffrepository.rngit.upstream.syncTa5d6ff`` - Unix timestamp of last successful sync for mirrors
These parameters are used by the sync system and can be queried using standard Git commands:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ git config --get repository.rngit.type
mirror
$ git config --get repository.rngit.upstream.source
https://github.com/user/upstream
$ git config --get repository.rngit.upstream.sync
1716230400
Tc9d1d9Repository Structure
Tc9d1d9====================
The Ta5d6ff``Ta5d6ffrngitTa5d6ff`` node organizes repositories into groups. Each group is a directory containing bare Git repositories. The repository path format is Ta5d6ff``Ta5d6ffgroup_name/repo_nameTa5d6ff``. For example, a repository at Ta5d6ff``Ta5d6ff/var/git/public/myrepoTa5d6ff`` would be accessible as Ta5d6ff``Ta5d6ffpublic/myrepoTa5d6ff`` via the URL Ta5d6ff``Ta5d6ffrns://DESTINATION_HASH/public/myrepoTa5d6ff``.
Tc9d1d9Configuration
Tc9d1d9-------------
The Ta5d6ff``Ta5d6ffrngitTa5d6ff`` node configuration file is located at Ta5d6ff``Ta5d6ff~/.rngit/configTa5d6ff`` (or Ta5d6ff``Ta5d6ff/etc/rngit/configTa5d6ff`` for system-wide installations). The default configuration includes:
T79c0ff- Repository group paths defining where to find bare repositories
T79c0ff- Access permissions for groups and individual repositories
T79c0ff- Announce intervals for network visibility
T79c0ff- Optional statistics recording for repository activity
Tc9d1d9Permissions
Tc9d1d9===========
The Ta5d6ff``Ta5d6ffrngitTa5d6ff`` permission system provides fine-grained access control at multiple levels: group-level, repository-level, and document-level. Permissions can be statically configured in files or dynamically generated via executable scripts.
Access permissions can be configured at the group level in the config file or per-group Ta5d6ff``Ta5d6ff.allowedTa5d6ff`` files, or per-repository Ta5d6ff``Ta5d6ff.allowedTa5d6ff`` files. The Ta5d6ff``Ta5d6ffsTa5d6ff`` (stats) permission allows viewing repository activity statistics, including views, fetches and pushes over time. To enable statistics recording, set Ta5d6ff``Ta5d6ffrecord_stats = yesTa5d6ff`` in the Ta5d6ff``Ta5d6ff[rngit]Ta5d6ff`` section of the configuration file. You can also exclude specific identities from statistics by adding their hashes to Ta5d6ff``Ta5d6ffstats_ignore_identitiesTa5d6ff``.
By default, **no** permissions are granted for anything! You will have to enable the permissions you require to be able to actually *do* something with Ta5d6ff``Ta5d6ffrngitTa5d6ff``.
Permissions can be modified by editing the Ta5d6ff``Ta5d6ffrngitTa5d6ff`` config file, individual Ta5d6ff``Ta5d6ff.allowedTa5d6ff`` files on disk, or remotely using the Ta5d6ff``Ta5d6ffrngit permsTa5d6ff`` command.
Tc9d1d9Permission Types
Tc9d1d9----------------
The following permissions are supported:
T79c0ff- Ta5d6ff``Ta5d6ffrTa5d6ff`` (read) - Clone, fetch, and view repositories and work documents
T79c0ff- Ta5d6ff``Ta5d6ffwTa5d6ff`` (write) - Push changes and manage work documents
T79c0ff- Ta5d6ff``Ta5d6ffrwTa5d6ff`` (read/write) - Combined read and write access
T79c0ff- Ta5d6ff``Ta5d6ffcTa5d6ff`` (create) - Create, fork or mirror new repositories within a group
T79c0ff- Ta5d6ff``Ta5d6ffsTa5d6ff`` (stats) - View repository activity statistics
T79c0ff- Ta5d6ff``Ta5d6ffrelTa5d6ff`` (release) - Create and manage releases
T79c0ff- Ta5d6ff``Ta5d6ffiTa5d6ff`` (interact) - Comment on and interact with work documents
T79c0ff- Ta5d6ff``Ta5d6ffpTa5d6ff`` (propose) - Propose new work documents (without full write access)
T79c0ff- Ta5d6ff``Ta5d6ffadmTa5d6ff`` (admin) - Full access
Permission targets can be:
T79c0ff- Ta5d6ff``Ta5d6ffallTa5d6ff`` or Ta5d6ff``Ta5d6ffaTa5d6ff`` - Everyone
T79c0ff- Ta5d6ff``Ta5d6ffnoneTa5d6ff`` or Ta5d6ff``Ta5d6ffnTa5d6ff`` - Nobody
T79c0ff- A specific Reticulum identity hash
Tc9d1d9Permission Hierarchy
Tc9d1d9--------------------
Permissions are resolved in the following hierarchy:
T79c0ff1. **Repository-level permissions** - Checked first, if none exists group permissions are checked
T79c0ff2. **Group-level permissions** - Used as fallback if no repository-level permissions are set
T79c0ff3. **Admin override** - Finally, potential admin rights are checked
For work documents, work document specific permissions are always checked first, and work documents have additional specific checks such as modifications only being possible by the document author.
Tc9d1d9Configuration Methods
Tc9d1d9---------------------
**Group-Level Configuration**
Group permissions can be configured in the Ta5d6ff``Ta5d6ff[access]Ta5d6ff`` section of the main config file:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
[access]
public = r:all, w:9710b86ba12c42d1d8f30f74fe509286
internal = rw:9710b86ba12c42d1d8f30f74fe509286
collaborative = r:all, i:all, p:all, w:9710b86ba12c42d1d8f30f74fe509286
Additionally, they can be configured in a group Ta5d6ff``Ta5d6ffgroup_name.allowedTa5d6ff`` file, placed next to the Ta5d6ff``Ta5d6ffgroup_nameTa5d6ff`` group directory.
**Repository-Level Configuration**
Repository-specific permissions are set in Ta5d6ff``Ta5d6ff.allowedTa5d6ff`` files placed next to the repository directory (for example, Ta5d6ff``Ta5d6ffmyrepo.allowedTa5d6ff`` for Ta5d6ff``Ta5d6ffmyrepoTa5d6ff``):
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
# myrepo.allowed
r:all
w:9710b86ba12c42d1d8f30f74fe509286
rel:9710b86ba12c42d1d8f30f74fe509286
**Dynamic Permissions**
Permission files can be made executable to generate permissions dynamically:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ chmod +x myrepo.allowed
When executable, the script is run and its stdout is parsed as permission rules. This allows integration with external authentication systems.
Tc9d1d9Work Document Permissions
Tc9d1d9-------------------------
Work documents support additional permission granularity through Ta5d6ff``Ta5d6ff.allowedTa5d6ff`` files in the work directory (e.g., Ta5d6ff``Ta5d6ff42.allowedTa5d6ff`` for document #42). These files use the same permission syntax but only support:
T79c0ff- Ta5d6ff``Ta5d6ffrTa5d6ff`` (read) - View the document
T79c0ff- Ta5d6ff``Ta5d6ffwTa5d6ff`` (write) - Edit the document
T79c0ff- Ta5d6ff``Ta5d6ffiTa5d6ff`` (interact) - Comment on the document
T79c0ff- Ta5d6ff``Ta5d6ffpTa5d6ff`` (propose) - Propose changes (future use)
T79c0ff- Ta5d6ff``Ta5d6ffadmTa5d6ff`` (admin) - Full control over the document
Document permissions override repository permissions for that specific document. Work document permissions can be updated simply by editing the Ta5d6ff``Ta5d6ff.allowedTa5d6ff`` file, or remotely by using the Ta5d6ff``Ta5d6ffrngit workTa5d6ff`` command.
Tc9d1d9Creator Permissions
Tc9d1d9-------------------
When a user creates a repository (via Ta5d6ff``Ta5d6ffcreateTa5d6ff``, Ta5d6ff``Ta5d6ffforkTa5d6ff``, or Ta5d6ff``Ta5d6ffmirrorTa5d6ff``), they are automatically granted Ta5d6ff``Ta5d6ffadmTa5d6ff`` (admin) permissions on that repository.
When a user creates a work document, they automatically receive Ta5d6ff``Ta5d6ffinteractTa5d6ff`` and Ta5d6ff``Ta5d6ffwriteTa5d6ff`` permissions on that document.
Tc9d1d9Permission Examples
Tc9d1d9-------------------
**Example 1: Public Read, Restricted Write**
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
r:all
w:9710b86ba12c42d1d8f30f74fe509286
Everyone can read, only the specified identity can write.
**Example 2: Collaborative Development**
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
r:all
i:all
p:all
w:9710b86ba12c42d1d8f30f74fe509286
rel:9710b86ba12c42d1d8f30f74fe509286
Everyone can read, interact (comment), and propose work documents. Only the specified identity can write, create releases, and manage work documents fully.
**Example 3: Private Repository**
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
rw:9710b86ba12c42d1d8f30f74fe509286
rw:a1b2c3d4e5f686ba12c42d1ba12ef1aa
Only the two specified identities have any access (read or write).
**Example 4: Mirror with Stats**
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
r:all
s:all
w:none
Everyone can read and view stats, but nobody can push (mirror is read-only from upstream).
Tc9d1d9Permission Short Forms
Tc9d1d9----------------------
Permissions can be specified using short or long forms:
T79c0ff- Ta5d6ff``Ta5d6ffrTa5d6ff`` = Ta5d6ff``Ta5d6ffreadTa5d6ff``
T79c0ff- Ta5d6ff``Ta5d6ffwTa5d6ff`` = Ta5d6ff``Ta5d6ffwriteTa5d6ff``
T79c0ff- Ta5d6ff``Ta5d6ffrwTa5d6ff`` = Ta5d6ff``Ta5d6ffreadwriteTa5d6ff``
T79c0ff- Ta5d6ff``Ta5d6ffcTa5d6ff`` = Ta5d6ff``Ta5d6ffcreateTa5d6ff``
T79c0ff- Ta5d6ff``Ta5d6ffsTa5d6ff`` = Ta5d6ff``Ta5d6ffstatsTa5d6ff``
T79c0ff- Ta5d6ff``Ta5d6ffrelTa5d6ff`` = Ta5d6ff``Ta5d6ffreleaseTa5d6ff``
T79c0ff- Ta5d6ff``Ta5d6ffiTa5d6ff`` = Ta5d6ff``Ta5d6ffinteractTa5d6ff``
T79c0ff- Ta5d6ff``Ta5d6ffpTa5d6ff`` = Ta5d6ff``Ta5d6ffproposeTa5d6ff``
T79c0ff- Ta5d6ff``Ta5d6ffadmTa5d6ff`` = Ta5d6ff``Ta5d6ffadminTa5d6ff``
Targets can also use short forms:
T79c0ff- Ta5d6ff``Ta5d6ffaTa5d6ff`` = Ta5d6ff``Ta5d6ffallTa5d6ff`` = Ta5d6ff``Ta5d6ffeveryoneTa5d6ff``
T79c0ff- Ta5d6ff``Ta5d6ffnTa5d6ff`` = Ta5d6ff``Ta5d6ffnoneTa5d6ff`` = Ta5d6ff``Ta5d6ffnobodyTa5d6ff``
Tc9d1d9Permission Configuration Locations
Tc9d1d9----------------------------------
T79c0ff- User install: Ta5d6ff``Ta5d6ff~/.rngit/configTa5d6ff``
T79c0ff- System install: Ta5d6ff``Ta5d6ff/etc/rngit/configTa5d6ff``
T79c0ff- Group permissions: Ta5d6ff``Ta5d6ff<group_root>/<group_name>.allowedTa5d6ff``
T79c0ff- Repository permissions: Ta5d6ff``Ta5d6ff<group_root>/<group_name>/<repo_name>.allowedTa5d6ff``
T79c0ff- Document permissions: Ta5d6ff``Ta5d6ff<group_root>/<group_name>.work/<doc_id>.allowedTa5d6ff``
Tc9d1d9Remote Permission Management
Tc9d1d9============================
While permissions can be configured directly on the node by editing configuration files and Ta5d6ff``Ta5d6ff.allowedTa5d6ff`` files, Ta5d6ff``Ta5d6ffrngitTa5d6ff`` also supports remote permission management through the Ta5d6ff``Ta5d6ffrngit permsTa5d6ff`` command. This allows administrators to modify access controls for groups and repositories over Reticulum, without requiring shell access to the hosting node.
To use remote permission management, you must have Ta5d6ff``Ta5d6ffadminTa5d6ff`` permission on the target group or repository. The command opens your configured Ta5d6ff``Ta5d6ff$EDITORTa5d6ff`` to modify permissions, using the same syntax and format as local Ta5d6ff``Ta5d6ff.allowedTa5d6ff`` files. When you save and exit the editor, the modified permissions are transmitted to the remote node and applied immediately.
Tc9d1d9Managing Group Permissions
Tc9d1d9--------------------------
To view or modify permissions for an entire repository group, specify the group URL (ending with the group name):
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit perms rns://50824b711717f97c2fb1166ceddd5ea9/public
This retrieves the current permission configuration from the Ta5d6ff``Ta5d6ffpublic.allowedTa5d6ff`` file and opens it in your editor. Any changes you make are validated for syntax correctness. Invalid permission rules will be rejected with an error message indicating the problematic line.
Tc9d1d9Managing Repository Permissions
Tc9d1d9-------------------------------
To manage permissions for a specific repository, include the repository name in the URL:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit perms rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo
This operates on the Ta5d6ff``Ta5d6ffmyrepo.allowedTa5d6ff`` file next to the repository. Repository-level permissions take precedence over group-level permissions, allowing fine-grained access control for individual repositories within a group.
Tc9d1d9Permission Validation
Tc9d1d9---------------------
When modifying permissions remotely, Ta5d6ff``Ta5d6ffrngitTa5d6ff`` validates that:
T79c0ff- Each permission line follows the correct Ta5d6ff``Ta5d6ffpermission:targetTa5d6ff`` syntax
T79c0ff- Permission types are valid (r, w, rw, c, s, rel, i, p, adm)
T79c0ff- Target specifications are valid (identity hashes, Ta5d6ff``Ta5d6ffallTa5d6ff``, or Ta5d6ff``Ta5d6ffnoneTa5d6ff``)
T79c0ff- Identity hashes, when specified, are the correct length (32 hexadecimal characters)
If validation fails, the editor will reopen with an error message describing the issue, allowing you to correct the problem before resubmitting.
Tb4b4b4.. Tff7b72cautionTb4b4b4::
Remote permission modification requires administrative access (the Ta5d6ff``Ta5d6ffadmTa5d6ff`` permission), which grants full control over the repository or group. The permission change request is transmitted over the encrypted Reticulum link, and the remote node verifies your identity cryptographically before applying changes. However, be aware that granting Ta5d6ff``Ta5d6ffadmTa5d6ff`` permissions to remote identities effectively delegates full control, including the ability to revoke your own access or modify permissions in ways you may not anticipate.
**All Command-Line Options (rngit perms)**
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
usage: rngit perms [-h] [--config CONFIG] [--rnsconfig RNSCONFIG]
[-i PATH] [-v] [-q] [--version]
remote
Reticulum Git Permission Manager
positional arguments:
remote URL of remote group or repository
options:
-h, --help show this help message and exit
--config CONFIG path to alternative config directory
--rnsconfig RNSCONFIG
path to alternative Reticulum config directory
-i, --identity PATH path to identity
-v, --verbose
-q, --quiet
--version show program's version number and exit
Tc9d1d9Identity & Destination Aliases
Tc9d1d9==============================
To make permission and remote destination management easier, you can locally define aliases for commonly used identity and destination hashes. Identity aliases used in permissions resolution can be defined in the Ta5d6ff``Ta5d6ff[aliases]Ta5d6ff`` section of the Ta5d6ff``Ta5d6ff~/.rngit/configTa5d6ff`` file, while destination aliases are defined in the Ta5d6ff``Ta5d6ff[aliases]Ta5d6ff`` section of the Ta5d6ff``Ta5d6ff~/.rngit/client_configTa5d6ff`` file.
All alias definitions take the form of Ta5d6ff``Ta5d6ffaliased_name = HASHTa5d6ff``:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
[aliases]
alice = d09285e660cfe27cee6d9a0beb58b7e0
bob = ffcffb4e255e156e77f79b82c13086a6
**Aliases are always resolved locally!** If for example you fork a repository with Ta5d6ff``Ta5d6ffrngit fork rns://bobs_node/public/repo_name rns://my_node/forks/repo_nameTa5d6ff``, the forked repository will of course still reference the full, original destination hash, and use this for subsequent upstream syncs.
Tc9d1d9Serving Pages Over Nomad Network
Tc9d1d9================================
In addition to providing Git repository access via the Git remote helper protocol and command-line tools, Ta5d6ff``Ta5d6ffrngitTa5d6ff`` can also run a Ta5d6ff`Nomad Network Tffd700<https://github.com/markqvist/nomadnet>Ta5d6ff`_ compatible page node. This allows users to browse repository information, view file contents, inspect commit history and access repository statistics through any Nomad Network client.
When enabled, the page node provides a complete interface to your repositories, with automatic Markdown to Micron conversion, syntax-highlighted code browsing, and detailed commit, diff and statistics views.
Tc9d1d9Enabling the Git Page Node
Tc9d1d9--------------------------
To enable the page node, add the following to your Ta5d6ff``Ta5d6ff~/.rngit/configTa5d6ff`` file:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
[pages]
serve_nomadnet = yes
When the page node is enabled, Ta5d6ff``Ta5d6ffrngitTa5d6ff`` will listen on a Nomad Network node destination in addition to the Git repository destination. You can view the destination hash by running:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit --print-identity
Git Peer Identity : <959e10e5efc1bd9d97a4083babe51dea>
Repository Node Identity : <153cb870b4665b8c1c348896292b0bad>
Repositories Destination : <0d7334d411d00120cbad24edf355fdd2>
Nomad Network Destination : <50824b711717f97c2fb1166ceddd5ea9>
Tc9d1d9Accessing Repository Pages
Tc9d1d9--------------------------
Once the page node is running, you can access it from any Nomad Network client by connecting to the Nomad Network destination. The page node provides the following views:
T79c0ff- **Front Page** - Lists all repository groups accessible to your identity
T79c0ff- **Group Page** - Shows all repositories within a group
T79c0ff- **Repository Page** - Displays repository overview, description and README
T79c0ff- **Releases** - List of releases for the repository, with information and downloads
T79c0ff- **File Browser** - Browse directory trees and view and download file contents
T79c0ff- **Commits View** - View commit history with pagination
T79c0ff- **Commit Details** - Detailed commit information with file changes and diffs
T79c0ff- **Refs View** - List branches and tags
T79c0ff- **Statistics** - Activity charts showing views, fetches and pushes over time
All pages respect the same permission system used for Git access. If an identity does not have read access to a repository, they will not be able to view its pages.
Tc9d1d9Formatting & Syntax Highlighting
Tc9d1d9--------------------------------
If the Ta5d6ff``Ta5d6ffpygmentsTa5d6ff`` Python module is installed on your system, the page node will automatically apply syntax highlighting to code files. The highlighting supports a wide range of programming languages and uses a color theme optimized for terminal display.
To enable syntax highlighting, install pygments:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
pip install pygments
**Markdown & Micron Support**
README files and other Markdown documents are automatically converted to Micron markup for display in Nomad Network clients. You can also write your README files directly in Micron, in which case they will display and render as such in any Nomad Network client. The file browser also supports viewing both rendered and raw Markdown and Micron documents.
Code blocks in Markdown can include language hints for syntax highlighting:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
```python
def hello_world():
print("Hello, Reticulum!")
```
You can use Ta5d6ff``Ta5d6ffrawmuTa5d6ff`` code blocks to render raw Micron inside Markdown files. If you create a code block with the language hint Ta5d6ff``Ta5d6ffrawmuTa5d6ff``, everything inside it will be treated as Micron directly.
Tc9d1d9Customizing Templates
Tc9d1d9---------------------
The page node uses a template system that allows complete customization of the generated pages. Templates are stored in the Ta5d6ff``Ta5d6ff~/.rngit/templates/Ta5d6ff`` directory as Micron files.
The following template files are supported:
T79c0ff- Ta5d6ff``Ta5d6ffbase.muTa5d6ff`` - Base template wrapping all pages
T79c0ff- Ta5d6ff``Ta5d6fffront.muTa5d6ff`` - Front page listing all groups
T79c0ff- Ta5d6ff``Ta5d6ffgroup.muTa5d6ff`` - Group page listing repositories
T79c0ff- Ta5d6ff``Ta5d6ffrepo.muTa5d6ff`` - Repository overview page
T79c0ff- Ta5d6ff``Ta5d6ffreleases.muTa5d6ff`` - Release list page
T79c0ff- Ta5d6ff``Ta5d6ffrelease.muTa5d6ff`` - Release details page
T79c0ff- Ta5d6ff``Ta5d6fftree.muTa5d6ff`` - File browser pages
T79c0ff- Ta5d6ff``Ta5d6ffblob.muTa5d6ff`` - File content display
T79c0ff- Ta5d6ff``Ta5d6ffcommits.muTa5d6ff`` - Commit history listing
T79c0ff- Ta5d6ff``Ta5d6ffcommit.muTa5d6ff`` - Individual commit detail page
T79c0ff- Ta5d6ff``Ta5d6ffrefs.muTa5d6ff`` - Branches and tags listing
T79c0ff- Ta5d6ff``Ta5d6ffstats.muTa5d6ff`` - Statistics page
Templates can include the following variables:
T79c0ff- Ta5d6ff``Ta5d6ff{PAGE_CONTENT}Ta5d6ff`` - The main content of the page (required)
T79c0ff- Ta5d6ff``Ta5d6ff{NODE_NAME}Ta5d6ff`` - The configured node name
T79c0ff- Ta5d6ff``Ta5d6ff{NAVIGATION}Ta5d6ff`` - Breadcrumb navigation links
T79c0ff- Ta5d6ff``Ta5d6ff{VERSION}Ta5d6ff`` - The rngit version number
T79c0ff- Ta5d6ff``Ta5d6ff{GEN_TIME}Ta5d6ff`` - Page generation time
**Dynamic Templates**
Templates can be made executable to generate dynamic content. If a template file has the executable bit set, it will be executed and its stdout used as the template content.
**Icon Sets**
By default, the page node uses Nerd Font icons. If you prefer simpler icons or your terminal does not support Nerd Fonts, you can enable Unicode icons instead:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
[pages]
serve_nomadnet = yes
unicode_icons = yes
Tc9d1d9Repository Statistics
Tc9d1d9---------------------
When statistics recording is enabled (see the Ta5d6ff``Ta5d6ffrecord_statsTa5d6ff`` configuration option), the page node can display activity charts for each repository. The statistics page shows:
T79c0ff- Total and peak views, downloads, fetches and pushes
T79c0ff- Daily activity charts over a 90-day period
T79c0ff- Combined activity visualization
To view statistics, a user must have the Ta5d6ff``Ta5d6ffsTa5d6ff`` (stats) permission for the repository. See the Access Configuration section for details on setting permissions.
**Repository Thanks**
The page node includes a "Thanks" feature that allows users to express appreciation for a repository. On each repository page, a "Thanks" link is displayed showing the current thanks count. Clicking this link registers a thank you for the repository.
Tc9d1d9Configuration Example
Tc9d1d9---------------------
A complete node configuration might look like this:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
[rngit]
node_name = My Git Node
announce_interval = 360
record_stats = yes
[repositories]
public = /var/git/public
internal = /var/git/internal
[access]
public = r:all
internal = rw:9710b86ba12c42d1d8f30f74fe509286
[pages]
serve_nomadnet = yes
unicode_icons = no
Tc9d1d9Verified Releases
Tc9d1d9=================
The Ta5d6ff``Ta5d6ffrngitTa5d6ff`` release system provides cryptographic provenance and integrity guarantees through automatic signing of release artifacts and signed release manifests. When you create a release, Ta5d6ff``Ta5d6ffrngitTa5d6ff`` generates an Ed25519 signature for each artifact and embeds these signatures in a cryptographically signed release manifest (Ta5d6ff``Ta5d6ff.rsmTa5d6ff`` file). This allows anyone who obtains the release to verify its authenticity and integrity, regardless of how the files were distributed.
Tb4b4b4.. Tff7b72_git-release-obtain:
Tc9d1d9Obtaining Verified Releases
Tc9d1d9---------------------------
The Ta5d6ff``Ta5d6ffrngitTa5d6ff`` system lets you obtain releases securely and in a verified manner, by validating cryptographically signed release manifests in the Ta5d6ff``Ta5d6ff.rsmTa5d6ff`` format during the retrieval process. Once a release has been published with Ta5d6ff``Ta5d6ffrngitTa5d6ff``, anyone that has read access to it can obtain the release with the Ta5d6ff``Ta5d6ffrngit releaseTa5d6ff`` command, for example:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit release rns://remote_node/group/some_program fetch latest:all
This command will connect to the remote, retrieve the latest release manifest, verify it's signature and integrity (you can optionally specify a required signer identity with Ta5d6ff``Ta5d6ff--signerTa5d6ff``), and then download and sequentially verify all artifacts included in the release.
If verification succeeds, the retrieved artifact files, along with the release manifest will be saved in the current working directory. From the above example, you would end up with a number of downloaded files, and a version- and package specific release manifest, such as Ta5d6ff``Ta5d6ffsome_program_1.5.2.rsmTa5d6ff``.
Tb4b4b4.. Tff7b72importantTb4b4b4::
Keeping the retrieved release manifest is a **very** good idea! It allows you to easily obtain future releases and updates to the software directly, while verifying they came from the same publisher.
**Obtaining & Updating Releases Using RSM Manifests**
One of the key features of the Ta5d6ff``Ta5d6ffrngitTa5d6ff`` release system is the ability to fetch and verify new releases using only a signed release manifest. This is particularly valuable for distributing software over Reticulum. Once someone has an Ta5d6ff``Ta5d6ff.rsmTa5d6ff`` manifest of your package, they can use it to continually retrieve and update the software.
To fetch a release using a manifest:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit release some_program_1.5.2.rsm fetch latest:all
This command:
T79c0ff1. Validates the manifest signature to confirm authenticity
T79c0ff2. Extracts the origin node and repository path from the signed manifest
T79c0ff3. Connects to the origin node over Reticulum
T79c0ff4. Gets the *latest* release manifest from the developer
T79c0ff5. Verifies it against the existing manifest
T79c0ff6. Fetches each artifact listed in the manifest
T79c0ff7. Verifies each downloaded file against the signature embedded in the manifest
If any artifact fails signature verification, the fetch aborts with an error, preventing the installation of corrupted or tampered files.
**Specifying Required Signers**
You can require that releases be signed by specific identities. When fetching a release, use the Ta5d6ff``Ta5d6ff--signerTa5d6ff`` option to specify the identity hash of the required signer:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit release rns://remote_node/public/myrepo fetch latest:all --signer 21a8daa6d9c3d3b8aab6e94b6bcb0e33
If the release was not signed by the specified identity, the fetch will abort before any files are downloaded. Likewise, if any downloaded artifacts were not signed by the required identity, the process will abort at the first invalid signature. This provides strong guarantees about the provenance of the software you are installing.
The signer check also works when fetching from a local manifest:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit release manifest.rsm fetch latest:all --signer 21a8daa6d9c3d3b8aab6e94b6bcb0e33
**Selective & Partial Fetches**
You can fetch individual artifacts from a release by specifying the artifact name instead of Ta5d6ff``Ta5d6ffallTa5d6ff``:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit release rns://remote_node/public/myrepo fetch 1.2.0:myapp-1.2.0.tar.gz
This downloads only the specified artifact and verifies its signature against the manifest. If a file already exists locally, Ta5d6ff``Ta5d6ffrngitTa5d6ff`` verifies it against the manifest signature and skips the download if valid, making it safe to run the command multiple times. When fetching releases, Ta5d6ff``Ta5d6ffrngit releaseTa5d6ff`` will only download files that are missing or invalid according to the manifest. This means that partially completed release fetches can be continued later, if interrupted.
**Pattern Matching for Artifacts**
When fetching selective artifacts, you are not limited to exact names or the Ta5d6ff``Ta5d6ffallTa5d6ff`` keyword. You can use shell-style wildcard patterns to match multiple artifacts flexibly. This is particularly useful for selecting platform-specific builds, version ranges, or file types without specifying each file individually.
Tb4b4b4.. Tff7b72tipTb4b4b4::
When using pattern matching, make sure to enclose the target specification in quotes. Otherwise,
your shell will probably interpret it as a shell expansion pattern *before* it is passed as an
argument to Ta5d6ff``Ta5d6ffrngitTa5d6ff``!
The pattern matching supports standard Unix wildcards:
T79c0ff- Ta5d6ff``Ta5d6ff*Ta5d6ff`` matches any sequence of characters (including empty)
T79c0ff- Ta5d6ff``Ta5d6ff?Ta5d6ff`` matches any single character
T79c0ff- Ta5d6ff``Ta5d6ff[seq]Ta5d6ff`` matches any character in *seq* (for example Ta5d6ff``Ta5d6ff[0-9]Ta5d6ff`` or Ta5d6ff``Ta5d6ff[abc]Ta5d6ff``)
T79c0ff- Ta5d6ff``Ta5d6ff[!seq]Ta5d6ff`` matches any character not in *seq*
For example, to fetch all wheel files for Python 3 across any platform:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit release rns://remote_node/public/myrepo fetch "1.2.0:*-py3-*.whl"
To fetch a specific patch version when you know the major and minor version:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit release rns://remote_node/public/myrepo fetch "1.2.0:myapp-1.2.?-linux-x86_64.tar.gz"
Or to retrieve all source archives:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit release rns://remote_node/public/myrepo fetch "1.2.0:source_*.tgz"
If your pattern contains no wildcard characters, it must match an artifact name exactly, which is useful for fetching single, specific artifacts. When a pattern matches multiple artifacts, all matched files are fetched and verified. If no artifacts match the pattern, the fetch aborts with an error indicating no matches were found.
Tc9d1d9Offline Verification
Tc9d1d9--------------------
Because the release manifest contains embedded signatures, you can verify the integrity of release artifacts offline, without connecting to the repository node. The Ta5d6ff``Ta5d6ffrnidTa5d6ff`` and Ta5d6ff``Ta5d6ffrngitTa5d6ff`` utilities can validate artifact signatures against Ta5d6ff``Ta5d6ff.rsgTa5d6ff`` and manifest files.
**Using a release manifest:**
Ensure the release manifest is located in the same directory as the release artifacts, then run:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
# Verify all artifacts in the manifest
$ rngit release myapp-1.2.0.rsm verify
# Or, verify only specific artifacts
$ rngit release myapp-1.2.0.rsm verify "latest:*.whl"
This will load the manifest, and verify all files currently on-disk, but will not attempt to fetch the latest release manifest from the origin, or update local files to match it.
Tb4b4b4.. Tff7b72noteTb4b4b4::
The Ta5d6ff``Ta5d6ffverifyTa5d6ff`` operation is functionally equivalent to using the Ta5d6ff``Ta5d6fffetchTa5d6ff`` operation with the Ta5d6ff``Ta5d6ff--offlineTa5d6ff`` flag, and they can be used interchangably.
**For individual files:**
Ensure the Ta5d6ff``Ta5d6ff.rsgTa5d6ff`` signature is located in the same directory as the release artifact, then run:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rnid -V myapp-1.2.0.tar.gz
This validates that the artifact file matches the signature created during the release process. Combined with the manifest's own signature, this provides end-to-end verification from the original release creation to the final installation.
Tb4b4b4.. Tff7b72_git-release-create:
Tc9d1d9Creating Signed Releases
Tc9d1d9------------------------
Reticulum and the Ta5d6ff``Ta5d6ffrngitTa5d6ff`` system makes it easy to create signed releases that your users can verify and update securely. When you create a release using Ta5d6ff``Ta5d6ffrngitTa5d6ff``, the program automatically:
T79c0ff1. Generates an Ed25519 signature for each artifact file using your identity's signing key
T79c0ff2. Creates Ta5d6ff``Ta5d6ff.rsgTa5d6ff`` signature files alongside each artifact in your distribution directory
T79c0ff3. Constructs a signed Ta5d6ff``Ta5d6ffmanifest.rsmTa5d6ff`` release manifest containing metadata, an artifact list, and embedded signatures
T79c0ff4. Transmits both artifacts, signatures and manifest to the remote node specified as release origin
As an example, to create and publish a release from all files in the folder named Ta5d6ff``Ta5d6ffdistTa5d6ff``, simply run:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit release rns://my_node/group/myrepo create 1.2.0:./dist
Everything is automatically signed and uploaded to your node, and the release manifest will now include the following signed attestation information:
T79c0ff- Package name and version
T79c0ff- The release notes for this release
T79c0ff- Release timestamp and commit hash
T79c0ff- Origin node identity and repository path
T79c0ff- Complete list of artifacts
T79c0ff- Embedded signatures for each artifact
That's it, there's nothing more to it than one command. Users can now securely obtain your release using Ta5d6ff``Ta5d6ffrngit release fetchTa5d6ff``.
**Release Manifest Format**
Release manifests use the Ta5d6ff``Ta5d6ff.rsmTa5d6ff`` format (a general-purpose, structured signed message format) and are themselves cryptographically signed documents. The manifest format embeds the signing identity's public key and a detached signature that covers the entire manifest content. This creates a chain of trust: the manifest signature proves the manifest's authenticity, and the embedded artifact signatures prove each file's integrity.
When a release is created, the manifest is stored as Ta5d6ff``Ta5d6ffmanifest.rsmTa5d6ff`` in the release artifacts directory. You can also generate a local release manifest without uploading by using the Ta5d6ff``Ta5d6ff--localTa5d6ff`` flag:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit release rns://f2d31b2e080e5d4e358d32822ee4a3b7/public/myrepo create 1.2.0:./dist --local
This creates the Ta5d6ff``Ta5d6ff.rsgTa5d6ff`` signature files and Ta5d6ff``Ta5d6ffmanifest.rsmTa5d6ff`` in your local distribution directory without connecting to the remote node, allowing you to inspect or distribute the signed release through alternative channels.
**Signature File Format**
Individual artifact signatures use the Reticulum Signature (Ta5d6ff``Ta5d6ff.rsgTa5d6ff``) format and contain:
T79c0ff- The Ed25519 signature of the file
T79c0ff- The signing identity's public key
T79c0ff- Optional metadata, such as timestamps or notes
These signature files are created automatically during the release process and can be used independently of the manifest for verification purposes. The Ta5d6ff``Ta5d6ffrnidTa5d6ff`` utility can create and validate RSG signatures for any file, making this signature format useful beyond the Ta5d6ff``Ta5d6ffrngitTa5d6ff`` release system.
**Good Practices for Signature Distribution**
While release manifests in the Ta5d6ff``Ta5d6ff.rsmTa5d6ff`` format *include* embedded Ta5d6ff``Ta5d6ff.rsgTa5d6ff`` signatures for every listed artifact, it is dependent on the situation and requirements whether individual Ta5d6ff``Ta5d6ff.rsgTa5d6ff`` signatures are distributed as well. It is generally a good idea to do so, since they are very light-weight, and provide an easy and convenient way to validate and authenticate *individual* files, as opposed to entire releases.
When distributing software through multiple channels (direct download, mirror networks, physical media), including the Ta5d6ff``Ta5d6ff.rsmTa5d6ff`` manifest allows recipients to verify authenticity regardless of how they obtained the files. This is particularly valuable in low-connectivity environments where Reticulum may be the only available communication channel, as the manifest ensures that software updates can be verified even when received via store-and-forward mechanisms or physical media transport.
**Integration with Package Management**
While this functionality is still under development, the signed release manifest format is designed to be consumed by package management systems and automated deployment tools. Because the manifest is cryptographically signed and contains all necessary metadata and integrity checks, it can serve as a trusted source of truth for software distribution, even when fetched over untrusted channels or stored for long periods.
**Release Encryption**
While API primitives and command-line tools are currently not implemented for this, the release, distribution and verification system has been designed to also support *encrypted* releases, which can be distributed securely to authorized recipients.
**Verified Package Format**
The current system is being expanded to also include an Ta5d6ff``Ta5d6ff.rvpTa5d6ff`` package format, which can contain packaged releases including all relevant artifacts, metadata, manifest and signatures.
**Automated Mirror Discovery**
The Ta5d6ff``Ta5d6ffrngitTa5d6ff`` release system is designed to support automated mirror discovery and distribution package retrieval over Reticulum networks. Since everything is cryptographically signed and verified, it is possible to create automated mirror and distribution networks, where users can obtain software and information from local sources, without risking malicious modifications to the software they rely on. This functionality is currently in development.
Tc9d1d9Release Management
Tc9d1d9==================
In addition to hosting Git repositories, Ta5d6ff``Ta5d6ffrngitTa5d6ff`` provides a complete release management system. This allows you to publish versioned releases with associated artifacts, release notes and metadata. Releases are managed through the Ta5d6ff``Ta5d6ffrngit releaseTa5d6ff`` subcommand, and are also viewable through the Nomad Network page interface.
Tc9d1d9The Release Workflow
Tc9d1d9--------------------
Creating a release involves specifying a Git tag and a directory containing build artifacts or other files to distribute. The Ta5d6ff``Ta5d6ffrngitTa5d6ff`` client will open your configured Ta5d6ff``Ta5d6ff$EDITORTa5d6ff`` to compose release notes, then upload all artifacts to the remote repository node.
To create a release, specify the tag name and path to artifacts:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit release rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo create 1.2.0:./dist
This will:
T79c0ff1. Verify that the tag Ta5d6ff``Ta5d6ff1.2.0Ta5d6ff`` exists in the repository
T79c0ff2. Open your editor to write release notes
T79c0ff3. Upload all files from the Ta5d6ff``Ta5d6ff./distTa5d6ff`` directory
T79c0ff4. Publish the release
If no Ta5d6ff``Ta5d6ff$EDITORTa5d6ff`` environment variable is set, Ta5d6ff``Ta5d6ffrngitTa5d6ff`` will try to use Ta5d6ff``Ta5d6ffnanoTa5d6ff``, Ta5d6ff``Ta5d6ffvimTa5d6ff`` or Ta5d6ff``Ta5d6ffviTa5d6ff``. The editor will show a template with instructions. Lines starting with Ta5d6ff``Ta5d6ff#Ta5d6ff`` will be ignored, and if the remaining content is empty after stripping comments, the release creation will be cancelled.
Tc9d1d9Release Storage & Structure
Tc9d1d9---------------------------
Releases are stored on the node in a directory named Ta5d6ff``Ta5d6ffrepo_name.releasesTa5d6ff`` next to the bare repository. Each release is a subdirectory containing:
T79c0ff- Ta5d6ff``Ta5d6ffMETATa5d6ff`` - Release metadata in ConfigObj format
T79c0ff- Ta5d6ff``Ta5d6ffRELEASE.mdTa5d6ff`` or Ta5d6ff``Ta5d6ffRELEASE.muTa5d6ff`` - Release notes
T79c0ff- Ta5d6ff``Ta5d6ffartifacts/Ta5d6ff`` - All uploaded files
T79c0ff- Ta5d6ff``Ta5d6ffTHANKSTa5d6ff`` - Appreciation count from users
Tc9d1d9Command-Line Interaction
Tc9d1d9------------------------
**Listing Releases**
To view all releases for a repository:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit release rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo list
Tag Status Created Objs Notes
------------------------------------------------------------------
1.2.0 published 2025-01-15 14:32 3 Another release
1.1.0 published 2024-12-03 09:15 2 Bug fix release
1.0.0 published 2024-10-20 16:45 2 Initial release
**Viewing Release Details**
To see full information about a specific release:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit release rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo view 1.2.0
Release : 1.2.0
Status : published
Created : 2026-05-04 23:53:09
Thanks : 5
Release Notes
=============
Version 1.2.0 release notes...
Artifacts (4)
=============
- myapp-1.2.0.tar.gz (1.5 MB)
- myapp-1.2.0.zip (1.6 MB)
- checksums.txt (256 B)
**Fetching Releases**
To fetch a release, specify the remote URL, version and artifacts:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit release rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo fetch latest:all
This process is described in greater detail in the Te6edf3:ref:Te6edf3`Obtaining Verified Releases<git-release-obtain>` section.
**Creating Releases**
To fetch a release, specify the remote URL, version and artifacts:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit release rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo create 1.3.9:artifacts_dir
This process is described in greater detail in the Te6edf3:ref:Te6edf3`Creating Signed Releases<git-release-create>` section.
**Deleting Releases**
To remove a release:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit release rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo delete 1.2.0
Are you sure you want to delete release '1.2.0'? [y/N]: y
Release 1.2.0 deleted
**Requirements & Validation**
T79c0ff- The specified tag must exist in the remote repository
T79c0ff- You must have Ta5d6ff``Ta5d6ffreleaseTa5d6ff`` permission for the repository
T79c0ff- The target artifacts directory must exist and contain at least one file
T79c0ff- Release notes cannot be empty
**Permissions**
Release management requires the Ta5d6ff``Ta5d6ffreleaseTa5d6ff`` permission, configured the same way as other repository permissions. In the config file or Ta5d6ff``Ta5d6ff.allowedTa5d6ff`` files, use Ta5d6ff``Ta5d6ffrel:targetTa5d6ff`` to grant release management rights:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
# In .allowed file or config
rel:all # Allow everyone
rel:9710b86... # Allow specific identity
rel:none # Deny everyone
**Nomad Network Interface**
When the Nomad Network page node is enabled, releases are displayed on a dedicated releases page for each repository. Each release is listed with its tag, creation date, artifact count and a preview of the release notes. Clicking a release shows the full details including formatted release notes and a listing of all artifacts with their sizes.
**All Command-Line Options (rngit release)**
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
usage: python -m RNS.Utilities.rngit.server [-h] [--config CONFIG] [--rnsconfig RNSCONFIG]
[-i PATH] [-s PATH] [-n name] [-L]
[-o] [-v] [-q] [--version]
[repository] [operation] [target]
Reticulum Git Release Manager
positional arguments:
repository URL of remote repository, or path to RSM manifest
operation list, view, fetch, create, latest or delete
target tag and path to release artifacts directory
options:
-h, --help show this help message and exit
--config CONFIG path to alternative config directory
--rnsconfig RNSCONFIG
path to alternative Reticulum config directory
-i, --identity PATH path to release identity
-s, --signer PATH path to signing identity, if different from release identity
-n, --name name package name if different from repo name
-L, --local generate release locally, but don't upload
-o, --offline verify manifest locally, but don't fetch updates
-v, --verbose
-q, --quiet
--version show program's version number and exit
Tb4b4b4.. Tff7b72rawTb4b4b4:: latex
\newpage
Tc9d1d9Work Documents
Tc9d1d9==============
In addition to releases, Ta5d6ff``Ta5d6ffrngitTa5d6ff`` provides a work document management system for tracking tasks, investigations, issues and progress related to repositories. Work documents are stored as structured msgpack data and support threaded updates and comments.
Tc9d1d9Working With Work Documents
Tc9d1d9---------------------------
**Listing Work Documents**
To view work documents for a repository:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit work rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo list
Active documents
=================
ID Title Author Created Comments
---------------------------------------------------------------------------
1 Implemented new feature 9710b86ba12c4f2e… 2025-01-15 14:32 3
2 Fixed bug in parser 8f3a21c9d84e927b… 2025-01-14 09:15 1
Use Ta5d6ff``Ta5d6ff--scope completedTa5d6ff`` to view completed work documents, Ta5d6ff``Ta5d6ff--scope proposedTa5d6ff`` to view proposed documents, or Ta5d6ff``Ta5d6ff--scope allTa5d6ff`` to see all scopes.
**Viewing a Work Document**
To view a specific work document with all its comments:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit work rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo view -d 1
Implement new feature (active #1)
=================================
Author : 9710b86ba12c42d1d8f30f74fe509286
Status : active
Created : 2026-05-05 15:11:11
Edited : 2026-05-05 18:22:11
Format : markdown
Updates : 0
This work document tracks the implementation of the new feature...
Updates
=======
#1 by 9710b86ba12c42d1d8f30f74fe509286 at 2026-05-05 15:38:37
-------------------------------------------------------------
Initial analysis complete
**Creating Work Documents**
To create a new work document:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit work rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo create --title "Investigate performance issue"
This will open your configured Ta5d6ff``Ta5d6ff$EDITORTa5d6ff`` to compose the document content. Save and exit to create the document, or save an empty document to cancel.
**Editing Work Documents**
To edit an existing work document:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit work rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo edit -d 1
This fetches the current content, opens it in your editor, and sends any changes back to the node.
**Adding Comments**
To add an update to a work document:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit work rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo update -d 1
This opens your editor to compose the update.
Tc9d1d9Proposing Work Documents
Tc9d1d9------------------------
Users with Ta5d6ff``Ta5d6ffproposeTa5d6ff`` permission can create work document proposals without full Ta5d6ff``Ta5d6ffwriteTa5d6ff`` access. Proposals are created in a "proposed" state and must be activated by a user with appropriate permissions before becoming active.
To propose a work document:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit work rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo propose --title "Feature proposal"
This opens your editor to compose the proposal content. When saved, the document is created in the "proposed" scope. The creator automatically receives Ta5d6ff``Ta5d6ffinteractTa5d6ff`` and Ta5d6ff``Ta5d6ffwriteTa5d6ff`` permissions on the proposed document.
Proposed documents are visible through Ta5d6ff``Ta5d6ff--scope proposedTa5d6ff`` or Ta5d6ff``Ta5d6ff--scope allTa5d6ff``:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit work rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo list --scope proposed
**Permissions for Proposals**
T79c0ff- Creating proposals requires Ta5d6ff``Ta5d6ffproposeTa5d6ff`` permission on the repository
T79c0ff- The creator automatically gets Ta5d6ff``Ta5d6ffinteractTa5d6ff`` and Ta5d6ff``Ta5d6ffwriteTa5d6ff`` on their proposed document
T79c0ff- Activating a proposal requires Ta5d6ff``Ta5d6ffwriteTa5d6ff`` and Ta5d6ff``Ta5d6ffinteractTa5d6ff`` permissions
Tc9d1d9State Management
Tc9d1d9----------------
**Completing Work Documents**
To mark a work document as completed (moving it from Ta5d6ff``Ta5d6ffactiveTa5d6ff`` to Ta5d6ff``Ta5d6ffcompletedTa5d6ff``):
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit work rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo complete -d 1
Work document #1 completed
**Activating Work Documents**
To mark a work document as active (moving it from Ta5d6ff``Ta5d6ffcompletedTa5d6ff`` to Ta5d6ff``Ta5d6ffactiveTa5d6ff``):
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit work rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo activate -d 1
Work document #1 activated
**Deleting Work Documents**
To delete a work document and all its comments:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit work rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo delete -id 1
Are you sure you want to delete active work document #1? [y/N]: y
Work document #1 deleted
Tc9d1d9Managing Work Document Permissions
Tc9d1d9----------------------------------
Users with administrative access to a work document can manage its specific permissions. This allows fine-grained control over who can read, write, comment on, or administer individual work documents.
To view or edit permissions for a work document:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rngit work rns://50824b711717f97c2fb1166ceddd5ea9/public/myrepo perms -d 1
This opens your editor with the current permission configuration:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
r:all
i:9710b86ba12c42d1d8f30f74fe509286
adm:9710b86ba12c42d1d8f30f74fe509286
Permission rules follow the same format as repository permissions:
T79c0ff- Ta5d6ff``Ta5d6ffr:targetTa5d6ff`` - Grant read access
T79c0ff- Ta5d6ff``Ta5d6ffw:targetTa5d6ff`` - Grant write access
T79c0ff- Ta5d6ff``Ta5d6ffi:targetTa5d6ff`` - Grant interact (comment) access
T79c0ff- Ta5d6ff``Ta5d6ffadm:targetTa5d6ff`` - Grant admin access
Targets can be Ta5d6ff``Ta5d6ffallTa5d6ff``, Ta5d6ff``Ta5d6ffnoneTa5d6ff``, or a specific identity hash.
**Who Can Edit Permissions**
Document permissions can be edited by:
T79c0ff- The original author (if they also have Ta5d6ff``Ta5d6ffinteractTa5d6ff`` and Ta5d6ff``Ta5d6ffwriteTa5d6ff`` on the repository)
T79c0ff- Any user with Ta5d6ff``Ta5d6ffadminTa5d6ff`` permission on the document
T79c0ff- Repository admins (through inherited permissions)
**Permission Precedence**
Document-specific permissions override repository-level permissions for that document. If document permissions exist, they are checked first; if access is not granted there, repository permissions are checked.
**Author Rights:**
T79c0ff- Users can only edit or delete work documents they created
T79c0ff- The author is cryptographically verified from the interacting link's Ta5d6ff``Ta5d6ffremote_identityTa5d6ff``
T79c0ff- Document creators automatically receive Ta5d6ff``Ta5d6ffinteractTa5d6ff`` and Ta5d6ff``Ta5d6ffwriteTa5d6ff`` on their documents
**Storage Format**
Work documents are stored in a Ta5d6ff``Ta5d6ffrepo_name.workTa5d6ff`` directory next to the repository, containing:
T79c0ff- Ta5d6ff``Ta5d6ffactive/Ta5d6ff`` - Active work documents
T79c0ff- Ta5d6ff``Ta5d6ffcompleted/Ta5d6ff`` - Completed work documents
T79c0ff- Ta5d6ff``Ta5d6ffproposed/Ta5d6ff`` - Proposed work documents
Each document is a numbered directory containing:
T79c0ff- Ta5d6ff``Ta5d6ffrootTa5d6ff`` - The work document content and metadata (msgpack format)
T79c0ff- Ta5d6ff``Ta5d6ffNTa5d6ff`` - Numbered comment files (msgpack format)
**Nomad Network Interface**
When the Nomad Network page node is enabled, work documents are viewable through the nomadnet interface. The work page lists all documents with their status, and clicking a document shows its full content and updates.
Tc9d1d9Cryptographic Attribution
Tc9d1d9-------------------------
Every work document is cryptographically signed by its creator using their Reticulum identity. When you create or edit a document, Ta5d6ff``Ta5d6ffrngitTa5d6ff`` generates an Ed25519 signature of the content, which is stored alongside the document contents and verified by the remote node, or locally when viewing the work document through the command-line interface. This provides two essential guarantees:
T79c0ff- **Attribution:** Every document and comment can be cryptographically attributed to its actual author
T79c0ff- **Integrity:** Any modification to the content after creation would invalidate the signature
When viewing a work document, the signature validation status is displayed:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
Author : 9710b86ba12c42d1d8f30f74fe509286 (not locally validated)
Signature : Document not signed
Or, for valid signatures:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
Author : <9710b86ba12c42d1d8f30f74fe509286>
Signature : Valid
The "Valid" status indicates that the document content matches the author's signature, and that the signing identity corresponds to the stated author. This can be used to create tamper-proof records of project decisions, investigations, and discussions that cannot be repudiated, or modified by third parties without detection.
This cryptographic provenance is particularly valuable for distributed teams operating across trust boundaries. Because signatures are verified using the author's Reticulum identity public keys - which can be recalled from any transport node on the network - work documents provide authoritative records of who said what, and when, without requiring a central authority to notarize or validate the communication. Even if the repository node hosting the documents becomes unavailable, the signed document files themselves retain validity and can be verified independently using standard Reticulum identity tools.
**All Command-Line Options (rngit work)**
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
usage: rngit work [-h] [--config CONFIG] [--rnsconfig RNSCONFIG]
[-i PATH] [--scope SCOPE] [-t TITLE] [-d ID] [-v]
[-q] [--version]
[repository] [operation]
Reticulum Git Work Document Manager
positional arguments:
repository URL of remote repository
operation list, view, create, propose, edit, delete,
update, complete, activate or perms
options:
-h, --help show this help message and exit
--config CONFIG path to alternative config directory
--rnsconfig RNSCONFIG
path to alternative Reticulum config directory
-i, --identity PATH path to identity
--scope SCOPE document scope: active, completed, proposed or all
-t, --title TITLE document title for create/propose
-d, --id ID document ID
-v, --verbose
-q, --quiet
--version show program's version number and exit
Tb4b4b4.. Tff7b72_git-commit-signing:
Tc9d1d9Commit Signing
Tc9d1d9==============
The Ta5d6ff``Ta5d6ffrngitTa5d6ff`` system includes Ta5d6ff``Ta5d6ffrngcsTa5d6ff``, a Git commit signing and validation shim that enables commit signing and validation using Reticulum identities. By hooking into Git's SSH-based signing format, commits can be signed and verified using Reticulum identity keys directly.
Unlike traditional GPG and SSH-based commit signing, which relies on centralized keyservers, cumbersome co-signing procedures or manual per-signer setup, Reticulum commit signing uses self-contained RSG signatures, that can be deterministically resolved to Reticulum identity hashes.
This enables offline verification with no external infrastructure. The signature itself contains everything needed to cryptographically verify the signer's Reticulum identity and that the commit was signed correctly by the claimed identity.
Tc9d1d9Prerequisites
Tc9d1d9-------------
Before you can sign commits, you need a Reticulum identity with a private key. If you don't already have one, you can generate it using Ta5d6ff``Ta5d6ffrnidTa5d6ff``:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ rnid -g ~/.rngit/client_identity
New identity <1a54d64db7e8beca6f2c6cd17b0cb479> written to /home/user/.rngit/client_identity
The identity file must contain the private key to be usable for signing. The corresponding Reticulum identity hash will be used as the commit author identity.
Tc9d1d9Configuration
Tc9d1d9-------------
Git must be configured to use SSH-format signatures with the Ta5d6ff``Ta5d6ffrngcsTa5d6ff`` signing shim, which is included in RNS. You can configure this either globally or per-repository.
**Global Configuration**
Enabling Reticulum commit signing for all repositories is as simple as:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ git config --global gpg.format ssh
$ git config --global gpg.ssh.program rngcs
$ git config --global gpg.ssh.allowedsignersfile none
$ git config --global user.signingKey ~/.rngit/client_identity
With this configuration, all commits you sign with Ta5d6ff``Ta5d6ffgit commit -STa5d6ff`` will use your Reticulum identity.
Tb4b4b4.. Tff7b72noteTb4b4b4::
The Ta5d6ff``Ta5d6ffgpg.ssh.allowedsignersfileTa5d6ff`` configuration key **must** be *set* for Ta5d6ff``Ta5d6ffgitTa5d6ff`` to allow invoking the signing and verification shim. It is not actually used by Ta5d6ff``Ta5d6ffrngcsTa5d6ff``, and can be set to an arbitrary value. All validation operations happen exclusively based on the information in the embedded RSG data.
**Per-Repository Configuration**
To enable signing only for a specific repository:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ cd /path/to/repository
$ git config --local gpg.format ssh
$ git config --local gpg.ssh.program rngcs
$ git config --local gpg.ssh.allowedsignersfile none
$ git config --local user.signingKey ~/.rngit/client_identity
This is useful when you want to use different identities for different projects, or when only specific repositories require signed commits.
Tc9d1d9Author Identity Binding
Tc9d1d9-----------------------
For the signature to be valid, the Git author email **must** match the Reticulum identity hash of the signing key. You can configure this using a command like the following:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ git config --global user.email "1a54d64db7e8beca6f2c6cd17b0cb479"
When Ta5d6ff``Ta5d6ffrngcsTa5d6ff`` verifies a commit, it extracts both the Git author field of the signed commit message and the signer identity from the RSG signature, ensuring they match. This binding is necessary to prevent identity spoofing. If someone crafts a commit with your identity hash in the author field but signs with a different key, verification will fail.
Tc9d1d9Signing Commits
Tc9d1d9---------------
Once configured, sign commits using the standard Git Ta5d6ff``Ta5d6ff-STa5d6ff`` flag:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ git commit -S -m "Refactored module"
[master 8f7e6d5] Refactored module
This will create a self-contained RSG-formatted signature, encode the RSG payload using base64, and wrap it in an ASCII-armored SSH-formatted signature block. The signature is then stored in the commit object's signature header and includes:
T79c0ff- The SHA256 hash of the commit content
T79c0ff- The signer's Reticulum identity hash
T79c0ff- The signer's public key
T79c0ff- The actual signature of the complete envelope
Tc9d1d9Validating Commit Signatures
Tc9d1d9----------------------------
Commits are automatically validated when using Ta5d6ff``Ta5d6ffgit log --show-signatureTa5d6ff`` or Ta5d6ff``Ta5d6ffgit show --show-signatureTa5d6ff``. The Ta5d6ff``Ta5d6ffrngcsTa5d6ff`` shim handles all verification operations. If any step fails, verification fails and Git displays an error.
To view signature information for commits, use Git's standard Ta5d6ff``Ta5d6ff--show-signatureTa5d6ff`` option:
Tb4b4b4.. Tff7b72codeTb4b4b4:: Tff7b72text
$ git log --show-signature
commit 8f7e6d5c8f7e6d5c8f7e6d5c8f7e6d5c8f7e6d5
Good "git" signature for commit, signed with Reticulum Identity key <1a54d64db7e8beca6f2c6cd17b0cb479>
Author: Developer <1a54d64db7e8beca6f2c6cd17b0cb479>
Date: Mon Jan 15 09:30:00 2026 +0100
Refactored module
The output shows whether the commit signature is valid, and whether the author field matches the signing identity.
Tb4b4b4.. Tff7b72tipTb4b4b4::
If you want to display both the identity hash and LXMF address for authors, you can generate a Ta5d6ff``Ta5d6ff.mailmapTa5d6ff`` file that resolves identities to LXMF addresses with the following script:
Tb4b4b4 .. Tff7b72codeTb4b4b4::
#!/bin/bash
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"
cd $DIR
id_regex="<([0-9a-f]{32})( .*)*>"
extract_id="s/.*$id_regex/\1/g"
rm -f .mailmap
git shortlog -se | grep -Ee "$id_regex" | sed -r "$extract_id" | while read -r id ; do
if lxmf=$(rnid -i $id -H lxmf.delivery | grep -Ee "destination for this Identity is" | sed -r "$extract_id"); then
echo "<$id lxmf:$lxmf> <$id>" >> .mailmap
fi
done
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────